Open
Conversation
catilac
reviewed
Feb 19, 2026
Contributor
catilac
left a comment
There was a problem hiding this comment.
left questions and comments. i know there are updates coming from our offline discussion. really great :)
| value: &MaterialValue, | ||
| ) -> Result<()> { | ||
| match name { | ||
| "base_color" | "color" => { |
Contributor
There was a problem hiding this comment.
why use &str instead of enum?
Comment on lines
+56
to
+74
| pub fn set_property( | ||
| In((entity, name, value)): In<(Entity, String, MaterialValue)>, | ||
| material_handles: Query<&UntypedMaterial>, | ||
| mut standard_materials: ResMut<Assets<StandardMaterial>>, | ||
| ) -> Result<()> { | ||
| let untyped = material_handles | ||
| .get(entity) | ||
| .map_err(|_| ProcessingError::MaterialNotFound)?; | ||
| let handle = untyped | ||
| .0 | ||
| .clone() | ||
| .try_typed::<StandardMaterial>() | ||
| .map_err(|_| ProcessingError::MaterialNotFound)?; | ||
| let standard = standard_materials | ||
| .get_mut(&handle) | ||
| .ok_or(ProcessingError::MaterialNotFound)?; | ||
| pbr::set_property(standard, &name, &value)?; | ||
| Ok(()) | ||
| } |
Contributor
There was a problem hiding this comment.
this of all things makes me think of the slang thesis. in the larger scheme of things,
are you thinking that we will have something to represent components and a binding state?
from a being able to work with the "building blocks" of gfx -- being able to declare components based off of a prescribed set of interfaces (to start) and to compose them in entry points sounds ideal. definitely curious about your thoughts and insights here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds support for PBR materials based on Bevy's
StandardMaterial.At a high level, our material API is going to operate on named fields:
mat.set("foo", 1.0). This is the intended API for custom materials and largely mirrors how Processing4 handles itsShadertype. BecauseStandardMaterialis a built in, in this PR we handle it as a special case where we map field names to setting properties on theStandardMaterialasset struct. But, from the perspective of the user, we want a pbr material to basically feel like any other material, just one whose shader you don't control.Some more specific notes: